<p>Обычно проектом управляют несколько групп пользователей, во главе которых группа "Администраторы", обладающая максимальными полномочиями. Список групп и сценарии их работы определяются, как правило, в ТЗ на веб-проект. Для обеспечения максимальной защищенности веб-проекта от известных и будущих видов уязвимостей и вирусов, настоятельно рекомендуется дать каждой группе пользователей только те права, которые ей действительно нужны для выполнения бизнес задач по принципу увеличения привилегий - сначала удаляются все права, а затем добавляются только необходимые.</p>

<p>Например, если задача пользователя состоит в редактировании в подвале сайта номера телефона - для него создается группа, имеющая права ТОЛЬКО на редактирование данной информации и он не может отредактировать мимоходом пункт меню или страницу "О компании". Аналогично, если пользователь управляет двумя инфоблоками, допустим, новостями, он должен иметь возможность редактировать только эти два инфоблока, а не 50 других инфоблоков в придачу.</p>

<p>Для чего это делается?</p>

<ol>
<li>Для того, чтобы ограничить информацию для сотрудника, управляющего частью сайта, самой необходимой. Для чего сотруднику просматривать лицензионные ключи, хранимые в инфоблоке, если его задача - добавлять страницы с контентом?
<br><br>
<b>Учетная запись любого пользователя может быть теоретически взломана:</b>
<ul>
<br> — пароль может быть "подслушан" вирусом-трояном, находящемся на компьютере пользователя, и передан на другой компьютер (особенно актуально, если пользователям разрешено работать из дома);
<br> — пароль пользователя подсмотрен другим пользователем;
<br> — пользователь может записать пароль на листике и потерять листик, или записать пароль на мониторе;
<br> — пароль может быть перехвачен внутри локальной сети
<br> — слабый пароль может быть подобран методом перебора
 </ul>

<li></li>
 </ol>

<p>Так вот, полученные привилегии не должны быть критичными для безопасности веб-проекта. Одно дело - изменить телефон, другое - изменить информацию в 100 инфоблоках, а 50 - удалить.</p>

<p>Нередко эта практика нарушается, и большинство пользователей работают над веб-сайтом с правами администратора, что чрезвычайно опасно.</p>




<ol>
<li>Смотрим, какие группы определены в системе в разделе: "Настройки > Пользователи > Группы пользователей". Необходимо проверить доступы в каждой группе списка, кроме "Администраторы" (ее проверяем отдельно).</li>

<li>Для каждой группы на вкладке "Доступ" проверяем уровень доступа ко всем модулям системы. Если стоит уровень доступа "по умолчанию", проверяем что значит это уровень в настройках модуля: "Настройки > Настройки продукта > Настройки модулей > Название модуля > вкладка 'Доступ'", значение свойства "По умолчанию".

<br><br>Обычно выбрано консервативное значение этого свойства, например "Доступ запрещен".  Однако важно проверить, что его никто не поменял на иное. Разумеется, перед тем, как настраивать права группы на модули, следует изучить в документации, какие операции внутри модуля соответствуют выбранному уровню прав. Например, какие операции разрешены учетной записи при уровне доступа к модулю "Интернет-магазин": "Обработка заказов" - означает ли этот уровень доступа возможность просматривать лицевые счета Покупателей или нет и т.п.<br><br></li>

<li>Если группа имеет доступ к модулю "Управление структурой" на уровне "Редактирование файлов и папок", необходимо тщательно проверить, к каким файлам и папкам группе предоставлен доступ в разделе "Контент > Структура сайта > Файлы и папки". Если группа по ТЗ имеет право только на редактирование файлов в папке "/about/company", то нужно убедиться что она не может ничего сделать в других папках сайтов. Аналогично проверяется доступ к другим файлам:  меню, шаблоны сайта и т.д.</li>

<li>Просматриваем каждый инфоблок в проекте и проверяем права групп на него: "Контент > Информ. блоки > Типы информ. блоков > Название инфоблока > вкладка 'Доступ'". Если группе нужна информация из инфоблока, должен стоять уровень "Чтение", но никак не "Изменение", что очевидно.</li>

<li>Проверяем правильность настроенных прав группы в административном разделе, для чего авторизуемся под учетной записью группы в административную часть "/bitrix/admin" (если в ТЗ предусмотрена работа пользователей в административном разделе).

<p>Пользователь должен увидеть только то, на что ему даны права, допустим инфоблоки, некоторые папки с файлами, некоторые модули - и ничего лишнего. Иногда становится неожиданностью, что Покупатель магазина оказывается может зайти по адресу: "/bitrix/admin" и в административной части, например, отредактировать свой профиль  и т.п. Если это не нужно, доступ в административную часть нужно ограничить.</p></li>

<li>Проверяем правильность настроенных прав группы в публичной части сайта, для чего авторизуемся под учетной записью группы на сайте и выполняем предусмотренные для группы операции.

<p>Например, если группа редактирует страницы в определенных папках на сайте - учетная запись должна суметь выполнить данные операции без ошибок. Нередко проверяют работоспособность учетной записи, находящейся временно в группе "Администраторы", а когда учетную запись переводят в настроенную для нее группу - начинаются ошибки нехватки выделенных прав.</p></li>

<li>Проверяем количество учетных записей, находящихся в группе "Администраторы" - заходим в группу, смотрим на вкладке "Параметры" в подраздел "Пользователи в группе". Всем ли учетным записям в этой группе нужны административные права? Нередко в этой группе можно встретить "забытые" после интеграции учетные записи редакторов контента и т.п., что опасно.</li>
<li>Полезно проверить, какую информацию может найти на сайте пользователь в группе. Если в результатах поиска появляется "закрытая" для него информация - необходимо ограничить доступ группы к ней.</li>
 </ol>

<p>В результате аудита и тестирования настраиваются минимально необходимые для работы права групп, остаются только те административные учетные записи, которые действительно нужны и, соответственно, безопасность веб-решения существенно возрастает.</p>


